Maintaining the SIP Interface

The following information is available to maintain and troubleshoot SIP trunks:

• Maintenance Commands

• Maintenance Logs

Maintenance Commands

See SIP for information on the maintenance commands available for SIP peers.

Maintenance Logs

The following logs indicate maintenance information for the SIP link:

• SIP link state information

• Busy out/return to service command against SIP link

• Authentication request failure

• Successful registration

• Malicious call trace

• Media Negotiation

• User Agent/Server cache

SIP link state information

Busy out / return to service command against SIP link

Authentication request failure

The system maintains the authentication request failure counter on a per IP address basis, and it periodically logs the failure's relevant information (for example on every 5th failure for the IP address).

Registering and error handling

Each SIP trunk registers with its registrar and the following actions are performed:

• At startup time, it sends registration requests to its registrar with an initial expiration interval of 3600 seconds, and re-submits the registration request with its credentials (username and password) when challenged, that is, upon receiving 401 (Unauthorized) or 407 (Proxy Authentication Required) response from the registrar.

• If the registration is successful, that is, it receives 200 OK, the alarm for SIP links is re-calculated or cleared. The following maintenance log is posted:

NOTE: The xxxx in the log is the expiration interval confirmed by the registrar in the 200 OK response.

• It refreshes the binding at half time of the expiration interval confirmed by the registrar.

• If its registrar is changed from ESM during runtime, removes its binding from the old registrar and re-registers with the new one.

• If the FQDN of the MiVoice Business system is changed from ESM during run time, it updates its binding in the registrar.

• If the credentials are changed from ESM during run time, it uses the new credentials at next refreshing attempt when challenged. The same user name and password pair are shared between registration and SIP trunk calls. Hence the credentials for a SIP peer profile must be changed at both the service provider and the MiVoice Business system before a successful call can be established if the challenge scheme is desired.

• It removes its binding from the registrar upon a graceful shutdown. Regardless of the shutdown mode, graceful or ungraceful, each SIP trunk re-registers with its service provider at startup.

The following errors are handled:

• If the trunk receives 423 (Interval Too Brief), it re-registers with the expiration interval specified in the Min-Expire header of the 423 response.

• If the trunk receives 403 (Forbidden), it will not re-try until its credentials are updated. An alarm is raised and the following maintenance log is posted:

• If the trunk receives 500 (Server Error), the system retries using the value in the Retry-after header or 90 seconds if the header is not present. An alarm is raised and the following maintenance log is posted the first time this error is received:

• If no response is received from the registrar, the system retries registration every 90 seconds until a response is received from the registrar. An alarm is raised and the following maintenance log will be posted after the failure of the first attempt:

• For the rest of the error responses, no retry is attempted. An alarm is raised and the following maintenance log will be posted after the failure of the first attempt:

NOTE: The x in the log is the error response code received.

Malicious Call Trace

The system supports Malicious Call Trace on European ISDN interfaces only, and does not support it on the SIP interface. Malicious call SMDR records are recorded on the MiVoice Business system. Call control sends a DPNSS LLM to the SIP component when a user wishes to tag a call. MiVoice Business creates a maintenance log:

The SIPMH logs information about the Media IP address and port being used remotely:

INFO SIP – Maintenance 2005/08/08 04:56:12 Maintenance(0)

   Malicous Call Trace Id 0x12345 SendRecv

   Local IP: 10.10.10.20:9000

   Remote IP: 192.168.2.23:7892

The SSP logs information about the SIP signaling information:

INFO SIP – Maintenance 2005/08/08 04:56:12 Maintenance(0)

   Malicous Call Trace Id 0x12345

   To: 5234@10.10.10.10

   From: "Anon" anon@anonymous.invalid

   Contact: 192.168.2.23

If there are other useful headers, SSP logs them as well.

Media Negotiation

1) Incompatible packet rate capabilities

If a call requiring a non-standard packet rate is made to an endpoint that does not support variable packet rates, it will (if possible) produce the following log:

1 WARNING Media Negotiation 2008/02/02 12:00:00 MaintenanceLog(0)
Incompatible RTP packetization capabilities detected on call between SIP port xxxxxxxx and port xxxxxxxx

2) Simple call to SIP endpoint

When MiVoice Business sees SDP coming from a SIP endpoint that contains either no ptime parameter, or a ptime that is not equal to the packetization rate programmed against the SIP trunk, it will produce the following log:

1 INFO Media Negotiation 2008/02/02 12:00:00 MaintenanceLog(0)

Different RTP packetization rates detected on call between SIP endpoints.

The log above is only an INFO level log as it may be generated even if the parties on the actual phone call do not detect a problem.

3) Transiting the enterprise cluster

It is possible, though unlikely, that a call may enter a MiVoice Business cluster via one SIP trunk, and exit the cluster through another SIP trunk to a different service provider. If the two Service Providers require different packetization rates, the result may be one-way, no-way, or garbled audio. In such scenarios, the following log will be produced:

1 WARNING Media Negotiation 2008/02/02 12:00:00 MaintenanceLog(0)
Different RTP packetization rates (xx ms detected, yy ms programmed) detected on call.

SIP To Header: xxxxxxxxxx

SIP From Header: xxxxxxxxxx

SIP Contact Header: xxxxxxxxxx

This log will be generated on both gateway nodes.

4) Calls that require rates outside the supported range

The SIP Peer Profile form provides a range of packetization rates that calls across SIP trunks can be forced to use. If a SIP service provider requires media streams that use a packetization rate outside of this range the SIP call will likely  fail. In the event that the negotiation does not fail, the media stream will likely not be played properly by the endpoint. Nevertheless, if a call is detected that uses a non-supported rate, the following log will be generated:

1 WARNING Media Negotiation 2008/02/02 12:00:00 MaintenanceLog(0)
Unsupported RTP packetization rate of xx ms detected on call across SIP Peer xxxxxxxx.

User Agent/Server Cache

SIP trunk service providers typically identify themselves using the message header field 'User-Agent' or 'Server.' These contain a text description of its server, including the software product and version—for example:

User-Agent: Provider SIP Proxy 15.0-r152

Server: Provider SIP Gateway 14.2-r120

MiVoice Business caches both of these headers and informs the user of changes using a Maintenance INFO log. This can be useful in diagnosing SIP compatibility problems that might be introduced when the SIP Peer moves to a new revision of their software. Up to six different User-Agent/Server headers can be cached for each SIP trunk. The headers are usually the same since SIP trunks on MiVoice Business systems typically communicate with a specific service provider. The first of two examples below illustrates  the initial message you will see if the SIP peer uses these headers. Subsequent logs are generated when the headers differ (as the second example shows), indicating either that the service has changed or that the provider is using more than one header.

Example of initial Maintenance INFO log (User-Agent/Server match)

Maintenance INFO  - SIP Network Element xyz User-Agent/Server Header is 'Provider SIP Proxy 15.0-r152'

Example of subsequent Maintenance INFO log (User-Agent/Server differ)

Maintenance INFO  - SIP Network Element xyz is now/also using User-Agent/Server Header ' Provider SIP Gateway 14.2-r120'.  Service may have changed or Provider is using more than one Header.

If more than six different headers are received from a given service provider logging stops and a Maintenance WARNING log similar to the following is generated:

Maintenance WARNING - SIP Network Element xyz has received too many User-Agents/Servers Headers.  Disabling User-Agent/Server Notification.  Logging can be restarted by using Maintenance Command SIP STATS CLEAR

To restart logging, issue the SIP STATS CLEAR maintenance command.